Existing networking architectures for real-time (e.g. online) computer games have strengths and weaknesses.
A common architecture for networked computer games is client-server. In this architecture, players using a client device may each attach to a single node (server device). This server device may then authoritatively control all data objects or game objects related to an online game. The server device may send network packets to each client device to communicate changes in these data objects and their relationships with each other. When a client device wants to perform an action, it may communicate a request to perform the action to the server, which may then decide whether or not the action is valid, carry out the action, and communicate the relevant results back to interested clients. In this architecture, the server device may bear the brunt of all game logic.
In a client-server game, cheating may be difficult to accomplish, since one or more actions must be validated and carried out by the server device. For example, a client device implemented on a local computer of the user may not give his avatar more health or teleport around the world by hacking a value in memory.
Currently, the complexity of an online browser game may be limited due to reliance on the client-server architecture and the fact that server processing time may be relatively expensive. As online games get more complex, the amount of logic that needs to run on the server device may increase. This may cause the number of players that can be accommodated per server to drop (since each player requires more processing and the server has limited processing power), raising the cost of running the game.
A second known architecture used for online gaming is peer-to-peer.” In a peer-to-peer architecture, each player (peer) may connect to at least one other player. Each peer implemented by a local client device may be authoritative over at least a subset of the data objects relating to the game. When a player wishes to interact with a data object owned by another peer, the player must communicate the player's intents over the network. The owner may then decide if the request is valid, process the request, and send the relevant results to interested client devices. This architecture distributes game logic amongst the peers, but each peer may now be required to send much more data over the network (since it must talk and send updates to every other peer). There may also be problems with this architecture when peers disconnect, such as determining who will assume ownership of the objects owned by the disconnecting peer, who has the most up-to-date copy of the state of these objects, etc.
Since each peer may be authoritative over a subset of the data objects, a player can easily hack any data object that he has ownership of (which usually includes his own avatar). This makes peer-to-peer games an unpopular choice for online games on insecure platforms such as a personal computer.